home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 975 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.9 KB
  1. From: bill@gibbons.org (Bill Gibbons)
  2. Message-ID: <bill-0504961003150001@bgibbons.vip.best.com>
  3. X-Original-Date: Fri, 05 Apr 1996 10:03:15 -0800
  4. Path: in2.uu.net!bounce-back
  5. Date: 05 Apr 96 18:29:36 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: sample auto_ptr template
  9. Organization: -none-
  10. References: <009A04DA6A831C40.49800EAC@ittpub.nl> <4k0m72$gm1@jabba.lehman.com>
  11. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  12.     iQBFAgUBMWVmmuEDnX0m9pzZAQF9QQF/X8U1wHsSG5MfMA6oP7aJyay1/Ot+T4Om
  13.     Ufa+t2TzO2DoeG2/xLcU4I9/W0xzgFho
  14.     =kVwr
  15.  
  16. In article <4k0m72$gm1@jabba.lehman.com>, ajay@lehman.com (Ajay Kamdar) wrote:
  17.  
  18. > ... it is obvious that trying to support
  19. > the Taligent idiom [transfer of resource ownership] is requiring
  20. > considerable work, and
  21. > it is not clear that a clean solution exists. Greg and others
  22. > have tried admirably to come up with solutions, but the extensive
  23. > discussions in this newsgroup make it obvious that each of
  24. > the solutions leaves many things to be desired. Irrespecitve
  25. > of what the Taligent experience has been with this idiom,
  26. > the collective experience of the people who have participated
  27. > in these discussions (a sum total that far exceeds whatever
  28. > Taligent can muster) clearly indicates that the form required
  29. > to support the Taligent idiom leaves a lot to be desired.
  30.  
  31. Well, no.  There were more people actively using smart pointers
  32. at Taligent than there have been people discussing them here.
  33. But that isn't really the point...
  34.  
  35. > So why not forget about trying to support the Taligent idiom
  36. > in auto_ptr and stay with the original intent of providing a
  37. > standardized idiom for exception safety? There is no reason
  38. > why the two separate idioms should be married together in
  39. > one class. What ever happened to the concept of using the
  40. > right tool for the right job? It is perfectly ok
  41. > for Taligent to impose a particular idiom on Taligent users
  42. > -- the users of the Taligent framework have a choice whether
  43. > to use the framework or not. But it is another matter to stuff
  44. > a questionable form of the idiom down the throats of every C++
  45. > user by making it a part of the standard auto_ptr.
  46.  
  47. Transfer of ownership is not the end goal - the end goal is
  48. to make auto_ptr useful for the "resource acquisition is
  49. initialization" idiom.  That is very painful without transfer
  50. of ownership.
  51.  
  52. In particular, if you want to do the resource acquisition in a
  53. function called by the function which needs to hold the resource,
  54. there is no good exception-safe way to pass the pointer from the
  55. callee to the caller.
  56.  
  57. You can get close (at some cost in clarity):
  58.  
  59.     extern get_X(auto_ptr<X> &);
  60.     void f() {
  61.         auto_ptr<X> ptr;
  62.         get_X(ptr);   // uses reset() to pass the pointer
  63.         ...
  64.     }
  65.  
  66. but this requires very careful coding in get_X:
  67.  
  68.     void get_X(auto_ptr<X> &ptr) {
  69.         X *p = new X;
  70.         // WARNING: DO NOT RISK AN EXCEPTION AT THIS POINT
  71.         ptr.reset(p);
  72.         return;
  73.     }
  74.  
  75. which is now extremely error-prone.  Alternatively:
  76.  
  77.     void get_X(auto_ptr<X> &ptr) {
  78.         auto_ptr<X> p = new X;
  79.         ptr.reset(p.release());
  80.         return;
  81.     }
  82.  
  83. but this requires dealing with details of auto_ptr one should
  84. not need to worry about in ordinary code.
  85.  
  86. With copy semantics:
  87.  
  88.     extern auto_ptr<X> get_X();
  89.     void f() {
  90.         auto_ptr<X> ptr = get_X();
  91.         ...
  92.     }
  93.  
  94.    auto_ptr<X> get_X() {
  95.         return auto_ptr<X>(new X);
  96.     }
  97.  
  98. The easier it is to use auto_ptr, the more often it will be
  99. used when it is needed - and the more often it will be used
  100. correctly.
  101.  
  102.  
  103. -- Bill Gibbons (formerly at Taligent)
  104.  
  105. -- 
  106. Bill Gibbons
  107. bill@gibbons.org
  108. ---
  109. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  110. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  111. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  112. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  113. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  114.